This disclosure relates generally to locating resources in a network in a data processing system and more specifically to programmatic redirect management for locating resources in a network in the data processing system.
When a web page of a website has an universal resource locator (URL) address changed, the website could lose valuable page ranking with search engines and affiliate links for the webpage. The loss may occur because the search engines and affiliates are pointing to the old URL address, which is now an invalid URL address. As a result, a typical search engine optimization solution handles changes to page URLs by returning what is referred to as a “301 redirect” to a new page, rather than showing a default “404 page not found” exception that would otherwise be presented to a site visitor.
An existing approach for a “301 redirect” situation is usually managed at a web server level, for example, using a configuration file, such as .htaccess, providing a mapping of old URLs to corresponding replacement URLs. A typical drawback of the existing approach is that it incurs manual overhead and is error prone. For example, when a URL address of a web page is changed, a technical person must manually update the web server configuration file to create a redirect rule for the changed page. An entire URL is typically mapped to a corresponding entire URL. In another example, a concept of a linked keyword may be used to represent a mapping of one element to a set of elements of an URL to provide a one-to-many mapping of elements. Accordingly, this leads to additional overhead and potential for mistakes since business users may change URLs and not inform technical administrators unintentionally leading to a “404 page not found” exception.
In another example, a large number of mappings are required for an online retail site with thousands or millions of products. When using traditional redirects having a hierarchical URL structure (containing many URL tokens), such as Furniture/Chairs/LoungeChairs, a change made to one of the parent tokens in the hierarchy, such as “Furniture”, requires technical administrators to create more elaborate redirect rules or multiple rules to remap all the child tokens to respective new locations from within the configuration file of the web server. When the same URL address needs to be changed several times, while keeping all previous rules still active, the problem is compounded. In the example, changing Furniture can potentially impact URLs of hundreds of associated products. A URL token is a keyword representing a portion of or a complete URL of a web page in a site. Each of the tokens is separated from another token in the URL by separator characters (for example, a slash in the examples).
Yet another potential issue with the common approach to 301 redirects is that a mapping solution is typically web server specific. A web server specific implementation requires a different solution for each web server, thus increasing maintenance and a potential for error.
Using existing approaches typically requires storing URL-to-URL mappings, which map the original URLs to redirected URLs. Creating and managing the URL-to-URL mappings requires prior knowledge of URL structures to create the pre-formed URL mapping rules. As the structure of any of original URLs change, there is a high maintenance cost associated with updating these mappings.
Using the online store with the existing approaches as an example, when a change is made from the “Furniture” category to a “SpringFurniture” category then a mapping is required such as:                //Mapping Rule 1        From: http://www.yourstore.com/Furniture/ . . .        To: http://www.yourstore.com/SpringFurniture/ . . .        
Also, when multiple URL structures containing the same URL keyword (Furniture in this example) are present then mappings for each of these structures is needed, as in:                //Mapping Rule 1 From: http://www.yourstore.com/Furniture/ . . .        To: http://www.yourstore.com/SpringFurniture/ . . .        //Mapping Rule 2 From: http://www.yourstore.com/Sales/Furniture/ . . .        To: http://www.yourstore.com/Sales/SpringFurniture/ . . .        //Mapping Rule 3 From: http://www.yourstore.com/Sales/Outlet/Furniture/ . . .        To: http://www.yourstore.com/Sales/Outlet/SpringFurniture/ . . .        
Further, when “Sales” is updated to become “Discounts” the complexity of the mappings continually increases with the number of updated structures. While the example is a simple illustration, with each additional change to a URL the system needed to maintain the redirect relationships becomes more complex very quickly.